SRE 弹性能力：使用 Envoy 对应用进行速率限制

作者：dm03514 译者：杨传胜 原文：https://medium.com/dm03514-tech-blog/sre-resiliency-bolt-on-sidecar-rate-limiting-with-envoy-sidecar-5381bd4a1137

速率限制是缓解级联故障和防止耗尽共享资源的一种简单有效的方法。 Envoy 是一个功能丰富的代理，可以为任何服务轻松添加速率限制的功能。本文将介绍在不更改应用程序本身配置的前提下如何配置 Envoy 来强制对应用进行速率限制。

问题

你是否遇到过资源被大量的请求淹没或耗尽的情况？你的客户端是否具有回退重试或速率限制的逻辑？在微服务架构中，不对其使用量进行限制的资源很容易被客户端发出的大量请求所淹没。当然可能存在一定数量的客户端，这些客户端本身就已经实现了各种重试/回退和速率限制的策略。不对访问量进行限制的客户端会耗尽服务端的资源，从而使其他客户端无法访问服务，甚至有些客户端会一直发起请求，直到使服务完全不可用。

对 API 的使用进行约束的常用方法是启用速率限制。与基于 IP 的速率限制或者 web 框架提供的应用级别速率限制不同，Envoy 允许在 HTTP 层实现快速，高性能和可靠的全局速率限制。

上图中左侧的 ServiceClient 代表使用率特别高的客户端。在运行期间，它可以使负载均衡后端的所有服务实例流量饱和，并使其他更高优先级的客户端丢弃其请求。

Envoy 能够对网络级别的任何服务进行速率限制，而无需对应用程序进行任何修改。此外，由于 Envoy 工作在 7 层，也就是应用程序级别，所以它可以检查 HTTP 速率信息并对其进行速率限制。

在本教程中，vegata 负载测试工具用于模拟上述示例中的批处理作业。下图显示了请求速率大约为 500次/秒 的稳定状态。

译者注：首先克隆 grokking-go 项目，然后进入 bolt-on-out-of-process-rate-limits 目录

1. $ make load-test

2. echo "GET http://localhost:8080/slow" | vegeta attack -rate=500 -duration=0 | tee results.bin | vegeta report

在模拟后台作业期间，对 API 资源 /slow 的访问速率达到了每秒 3500 个请求，影响到了其他端点和客户端。

为了解决这个问题，下面的解决方案将使用 Envoy 强制限制请求速率为 500个请求/秒。但首先...

Envoy 是什么？

Envoy 是一个轻量级代理服务器，能够处理任何 TCP/IP/HTTP/GRPC/HTTP2 等协议的连接。它具有高度可配置性，并支持许多不同的插件。它还使可观察性成为一等公民。

在 Envoy 横空出世之前，应用程序级别的重试、延迟注入、速率限制和熔断都要通过应用程序本身的代码逻辑来实现。Envoy 将这些功能从应用程序中剥离出来，并让运维管理人员能够配置和启用这些功能，无需对应用程序本身作任何修改。

Envoy 的 官方文档 和 MattKlein 的文章提供了一个比我更好的对 Envoy 的介绍：

Envoy 是一款由 Lyft 开源的，使用 C++ 编写的高性能分布式代理，专为单体服务和应用而设计。它也被作为大型微服务框架 Istio service mesh 的通信总线和通用数据平面。通过借鉴 NGINX、HAProxy、硬件负载均衡器和云负载均衡器等解决方案，Envoy 作为一个独立的进程与应用程序一起运行，并通过与平台无关的方式提供一些高级特性，从而形成一个对应用透明的通信网格。当基础设施中的所有服务流量通过 Envoy 网格流动时，通过一致的可观察性，调整整体性能和添加更多底层特性，一旦发生网络和应用程序故障，能够很容易定位出问题的根源。

解决方案

所有代码和示例都可以在 GitHub 上找到。

下面给出具体的解决方案：

• 将 Envoy 配置为 API 负载均衡器的前端代理；仍然允许所有流量通过。

• 配置并运行全局速率限制服务。

• 配置 Envoy 使用全局速率限制服务。

我们需要一种方法来限制同一时间发出的请求数量，以便将 API 负载均衡器与请求达到高峰的客户端隔离，并确保其他客户端在执行这些批处理作业（通过 vegeta 来模拟）期间可以继续访问 API。为了达到这个目的，我们将 Envoy 代理和批处理客户端 vegeta 部署在同一台机器上。

通过将 Envoy 作为 Sidecar 与批处理客户端一起运行，在请求达到负载均衡之前就可以对请求进行速率限制。使用 Envoy 是一个很明智的选择，因为它具有高度可配置性，高性能，并且可以很好地处理 HTTP 请求之间的平衡。

将 Envoy 配置为 API 负载均衡器的前端代理

第一步是将 Envoy 配置为处于批处理作业客户端和 API 负载均衡器之间，客户端向 API 发起的所有请求都会首先经过 Envoy 的处理。首先需要让 Envoy 知道如何连接 API，然后再更新批处理作业的配置，使该客户端向 Envoy 发出请起，而不是直接向 API 发出请求。配置完之后的最终状态如下图所示：

此步骤仅通过 Envoy 来对 API 流量进行路由，尚未对应用进行速率限制。为了达到限速的目的，我们还需要做一些额外的配置：

cluster

Cluster 表示 Envoy 连接到的一组逻辑上相似的上游主机（在本示例中表示 API 负载均衡器）。Cluster 的配置非常简单：

1. clusters:

2.  - name: api

3.    connect_timeout: 1s

4.    type: strict_dns

5.    lb_policy: round_robin

6.    hosts:

7.    - socket_address:

8.        address: localhost

9.        port_value: 8080

在本示例中，我们运行了一个监听在 localhost:8080 上的 fakapi 来模拟上图中的负载均衡器。通过 Envoy 向 API 发出的任何请求都会被发送到 localhost:8080。

virtual_host

virtual_host 部分的配置用来确保所有请求都会路由到上面定义的 API 集群。

1. - name: api

2.  domains:

3.  - "*"

4.  routes:

5.  - match:

6.      prefix: "/"

7.    route:

8.      cluster: api

其余的配置文件用来确定 Envoy 本身监听在哪个地址以及 Envoy 与其他服务之间的连接规则。

1. static_resources:

2.  listeners:

3.  - name: listener_0

4.    address:

5.      socket_address: { address: 0.0.0.0, port_value: 10000}

6.    filter_chains:

7.    - filters:

8.      - name: envoy.http_connection_manager

9.        config:

10.          stat_prefix: ingress_http

11.          codec_type: AUTO

12.          route_config:

13.            name: remote_api

14.            virtual_hosts:

15.            - name: api

16.              domains:

17.              - "*"

18.              routes:

19.              - match:

20.                  prefix: "/"

21.                route:

22.                  cluster: api

23.          http_filters:

24.          - name: envoy.router

25.  clusters:

26.  - name: api

27.    connect_timeout: 1s

28.    type: strict_dns

29.    lb_policy: round_robin

30.    hosts:

31.    - socket_address:

32.        address: localhost

33.        port_value: 8080

34. admin:

35.  access_log_path: "/dev/null"

36.  address:

37.    socket_address:

38.      address: 0.0.0.0

39.      port_value: 9901

更新负载测试工具的参数，直接访问本地的 Envoy 代理，通过仪表板可以观察到 Envoy 正在接收流量。下图的 Envoy 仪表板来自 Grafana 官方仪表板仓库（Lyft 也提供了一份 Envoy 仪表板）。

1. $ make load-test LOAD_TEST_TARGET=http://localhost:10000 LOAD_TEST_RATE=500

2. echo "GET http://localhost:10000/slow" | vegeta attack -rate=500 -duration=0 | tee results.bin | vegeta report

上图显示 Envoy 现在正在接收客户端发送给 API 的所有请求，并将它们发送到上游的负载均衡器！

配置并运行全局速率限制服务

此步骤将配置运行 Lyft 开源的全局 速率限制 服务。运行该服务非常简单，只需要克隆它的代码仓库，修改一部分配置文件，然后通过 docker-compose 启动就行了。

首先克隆 Ratelimit 代码仓库并修改配置文件，更新 domain 字段以及 descriptor 字段的 key 和 value：

1. $ cat examples/ratelimit/config/config.yaml

1. ---

2. domain: apis

3. descriptors:

4.  - key: generic_key

5.    value: default

6.    rate_limit:

7.      unit: second

8.      requests_per_unit: 500

接下来使用docker-compose 的配置文件（ docker-compose.yml）来启动全局速率限制服务（详细步骤请参考 README）：

1. $ docker-compose down && docker-compose up

配置 Envoy 使用全局速率限制服务

最后一步是配置 Envoy 使用全局速率限制服务，以强制执行速率限制并降低对 API 的请求速率。配置生效后，Envoy 将会检查每个传入连接的速率限制，并根据上面的配置过滤掉一部分请求（限制最多 500 个请求/秒）。

开启了速率限制的 Envoy 配置文件如下所示：

1. static_resources:

2.  listeners:

3.  - name: listener_0

4.    address:

5.      socket_address: { address: 0.0.0.0, port_value: 10000}

6.    filter_chains:

7.    - filters:

8.      - name: envoy.http_connection_manager

9.        config:

10.          use_remote_address: true

11.          stat_prefix: ingress_http

12.          codec_type: AUTO

13.          route_config:

14.            name: remote_api

15.            virtual_hosts:

16.            - name: api

17.              domains:

18.              - "*"

19.              routes:

20.              - match:

21.                  prefix: "/"

22.                route:

23.                  cluster: api

24.              rate_limits:

25.                - stage: 0

26.                  actions:

27.                    - {generic_key: {descriptor_value: "default"}}

28.          http_filters:

29.          - name: envoy.rate_limit

30.            config:

31.              domain: apis

32.              stage: 0

33.          - name: envoy.router

34.  clusters:

35.  - name: api

36.    connect_timeout: 1s

37.    type: strict_dns

38.    lb_policy: round_robin

39.    hosts:

40.    - socket_address:

41.        address: localhost

42.        port_value: 8080

43.  - name: rate_limit_cluster

44.    type: strict_dns

45.    connect_timeout: 0.25s

46.    lb_policy: round_robin

47.    http2_protocol_options: {}

48.    hosts:

49.    - socket_address:

50.        address: localhost

51.        port_value: 8081

52. rate_limit_service:

53.    grpc_service:

54.        envoy_grpc:

55.            cluster_name: rate_limit_cluster

56.        timeout: 0.25s

57. admin:

58.  access_log_path: "/dev/null"

59.  address:

60.    socket_address:

61.      address: 0.0.0.0

62.      port_value: 9901

然后，我们以 1000个请求/秒 的速率（速率限制的2倍）运行负载测试工具：

1. $ make load-test LOAD_TEST_TARGET=http://localhost:10000 LOAD_TEST_RATE=1000

2. echo "GET http://localhost:10000/slow" | vegeta attack -rate=1000 -duration=0 | tee results.bin | vegeta report

可以查看一下 ratelimiter 服务的日志，日志中显示了它接收的请求和它进行速率限制检查的过程：

1. msg="cache key: apis_generic_key_default_1540829538 current: 35"

2. ratelimit_1        | time="2018-10-29T16:12:18Z" level=debug msg="cache key: apis_generic_key_default_1540829538 current: 34"

3. ratelimit_1        | time="2018-10-29T16:12:18Z" level=debug msg="cache key: apis_generic_key_default_1540829538 current: 33"

4. ratelimit_1        | time="2018-10-29T16:12:18Z" level=debug msg="cache key: apis_generic_key_default_1540829538 current: 31"

5. ratelimit_1        | time="2018-10-29T16:12:18Z" level=debug msg="cache key: apis_generic_key_default_1540829538 current: 32"

6. ratelimit_1        | time="2018-10-29T16:12:18Z" level=debug msg="cache key: apis_generic_key_default_1540829538 current: 42"

7. ratelimit_1        | time="2018-10-29T16:12:18Z" level=debug msg="starting get limit lookup"

8. ratelimit_1        | time="2018-10-29T16:12:18Z" level=debug msg="cache key: apis_generic_key_default_1540829538 current: 46"

9. ratelimit_1        | time="2018-10-29T16:12:18Z" level=debug msg="looking up key: generic_key_default"

10. ratelimit_1        | time="2018-10-29T16:12:18Z" level=debug msg="looking up key: generic_key_default"

11. ratelimit_1        | time="2018-10-29T16:12:18Z" level=debug msg="looking up key: generic_key_default"

12. ratelimit_1        | time="2018-10-29T16:12:18Z" level=debug msg="looking up key: generic_key_default"

13. ratelimit_1        | time="2018-10-29T16:12:18Z" level=debug msg="looking up key: generic_key_default"

如果速率限制功能无法生效，可以参考该 issue 中的讨论。

运行一段时间后，停止负载测试打印出测试报告，可以看到其中 1/2 的请求被 Envoy 限制了，被限制的请求的状态码为 429 ！！！

1. $ make load-test LOAD_TEST_TARGET=http://localhost:10000 LOAD_TEST_RATE=1000

2. echo "GET http://localhost:10000/slow" | vegeta attack -rate=1000 -duration=0 | tee results.bin | vegeta report

3. Requests      [total, rate]            128093, 1000.02

4. Duration      [total, attack, wait]    2m8.102168403s, 2m8.090470728s, 11.697675ms

5. Latencies     [mean, 50, 95, 99, max]  10.294365ms, 11.553135ms, 33.428287ms, 52.678127ms, 177.709494ms

6. Bytes In      [total, mean]            1207354, 9.43

7. Bytes Out     [total, mean]            0, 0.00

8. Success       [ratio]                  52.69%

9. Status Codes  [code:count]             200:67494  429:60599

10. Error Set:

11. 429 Too Many Requests

通过 Envoy 暴露的速率限制指标（ envoy_cluster_ratelimit_over_limit）或（ 4xx 响应）的速率来绘制仪表板，可以看到相应的可视化图表：

通过可视化 API 服务实际看到的请求数量，可以证明请求速率在 500个请求/秒 上下波动，这正是我们所期望的！

再查看一下 Envoy 传出的 API 连接，可以看到传出请求速率也在 500个请求/秒 上下波动！

实验成功！

总结

希望通过本文的讲解能让你明白配置 Envoy 以减轻贪婪客户端对 API 资源的消耗是多么简单。我发现这种模式非常有用，因为弹性能力是为应用开发更多功能的基础。在 Envoy 横空出世之前，应用程序级别的重试、延迟注入、速率限制和熔断都要通过应用程序本身的代码逻辑来实现。Envoy 将这些功能从应用程序中剥离出来，并让运维管理人员能够配置和启用这些功能，无需对应用程序本身作任何修改。Envoy 完全颠覆了我们对服务弹性能力的认知，希望你读这篇文章时能和我写这篇文章时一样兴奋！

参考资料

• https://www.datawire.io/envoyproxy/getting-started-lyft-envoy-microservices-resilience/

• https://www.envoyproxy.io/docs/envoy/latest/

• https://blog.turbinelabs.io/deploying-envoy-as-a-front-proxy-5b7e0a453f65

• http://blog.christianposta.com/microservices/00-microservices-patterns-with-envoy-proxy-series/

• https://blog.envoyproxy.io/introduction-to-modern-network-load-balancing-and-proxying-a57f6ff80236

• https://eng.lyft.com/announcing-ratelimit-c2e8f3182555

• https://github.com/dm03514/grokking-go/compare/blog/bolt-on-rate-limits?expand=1

相关阅读

Istio免费直播课程推荐

本课程来自 IBM 微课程，通过视频直播的方式帮助您快速了解 Istio，每周一期。

11月1日 Istio初探（已结束，由孙琳分享）

11月8日 周四晚8点Istio系列第二讲：上手Istio: 基本概念，安装并使用istio进行微服务流量管控

11月15日 Istio的安全管理

11月22日 Envoy

11月29日 使用Istio来监控和可视化微服务

12月6日 Istio mixer - 基本概念，策略、遥测与扩展

12月13日 Istio跨云管理方案解析

12月20日 Istio使用案例：Serverless 平台knative

详情请参考：IBM微讲堂之年度大戏《Istio系列》

点击【阅读原文】跳转到网站上浏览可以查看文中的链接。

• SOFAMesh（https://github.com/alipay/sofa-mesh）基于Istio的大规模服务网格解决方案

• SOFAMosn（https://github.com/alipay/sofa-mosn）使用Go语言开发的高性能Sidecar代理

合作社区

参与社区

以下是参与ServiceMesher社区的方式，最简单的方式是联系我！

• 加入微信交流群：关注本微信公众号后访问主页右下角有获取联系方式按钮，添加好友时请注明姓名-公司

• 社区网址：http://www.servicemesher.com

• Slack：https://servicemesher.slack.com （需要邀请才能加入）

• GitHub：https://github.com/servicemesher

• Istio中文文档进度追踪：https://github.com/servicemesher/istio-official-translation

• Twitter: https://twitter.com/servicemesher

• 提供文章线索与投稿：https://github.com/servicemesher/trans